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DETAILED ACTION 

1. This action is responsive to communications: Amendment filed 01/13/2010 and 
Information Disclosure Statement (IDS) Filed 03/25/2010. 

2. Claims 21-24, 28-32, and 34-35 are pending in the case. Claims 21 and 28 are 
independent claims. 

3. The rejection of claims under § 1 12 is withdrawn in view of Applicant's amendments 

Information Disclosure Statement 

4. The information disclosure statement filed 3/25/2010 fails to comply with 37 CFR 
1.98(a)(3) because it does not include a concise explanation of the relevance, as it is presently 
understood by the individual designated in 37 CFR 1.56(c) most knowledgeable about the 
content of the information, of each patent listed that is not in the English language. It has been 
placed in the application file, but the information referred to therein has not been considered. 
While there is a document entitled "translation of ref. 1" it is not clear what it is a translation of 
how which reference it refers too how it explains the relevance. 

Claim Rejections - 35 USC § 112 

5. The following is a quotation of the second paragraph of 35 U.S.C. 1 12: 

The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the 
subject matter which the applicant regards as his invention. 

6. Claims 21-24 and 28-32 are rejected under 35 U.S.C. 1 12, second paragraph, as being 
indefinite for failing to particularly point out and distinctly claim the subject matter which 
applicant regards as the invention. Claim 21 recites "a transmission. . ." It is not seen how that is 
part of the apparatus. For examining purposes only it will not be considered. 
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7. The independent claims recite supporting . . . with a framework. A framework at best is 
documentation. All the terms defining the framework are so vague as to be practically 
meaningless. It certainly is not understood how any elements of the framework "support" a user 
interface. The Office cannot determine the metes and bounds of such supporting. Therefore, for 
examining purposes only, the framework limitations will be considered to mean a user interface 
that supports a common framework. 

Claim Rejections - 35 USC §103 

8. The following is a quotation of 35 U.S. C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

9. This application currently names joint inventors. In considering patentability of the 
claims under 35 U.S.C. 103(a), the examiner presumes that the subject matter of the various 
claims was commonly owned at the time any inventions covered therein were made absent any 
evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1 .56 to point out 
the inventor and invention dates of each claim that was not commonly owned at the time a later 
invention was made in order for the examiner to consider the applicability of 35 U.S.C. 103(c) 
and potential 35 U.S.C. 102(e), (f) or (g) prior art under 35 U.S.C. 103(a). 

10. Claims 21-24 are rejected under 35 U.S.C. 103(a) as being unpatentable over Bayeh 
et al. (US 6633914 Bl, 10/14/2003) hereinafter Bayeh-914, and further in view of "Press 
return = Click button?" (8/1/1997) by Michael Cote, and further in view of Whalen. (US 
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5948066, September 7, 1999), and further in view of Salas et al. (US 6,230,185 Bl, 
05/08/2001). Microsoft TechNet, "Transmission Control Protocol" hereinafter TechNet, is 
cited as evidence regarding TCP. 

Regarding independent claim(s) 21, Bayeh teaches a server: 
that is a shared server (Fig. 2, several client share access) 
comprising an object manager (see below) 

configured to measure loading of a central processing and direct requests to the object 
manager on the basis of loading (keeps track of 'in-use' and doesn't forward request if the load is 
full). 

Bayeh teaches an object manager (web server software, col. 4, 11. 40-41): 

in data communication with a plurality of business objects (servlets, Fig. 2) 
interposed between said first and second clients and an application (servlet plug-in), 

comprises the business objects and one or more business 

components (servlets) i executing on the server computer (Fig. 2); 

control and monitor the business objects [dispatches them to the servlets or objects (col. 

5, 11. 2-15), as well tracks whether they are in-use (col. 1, 11. 60-62),] 

interact with a database that provides storage to the object manager (persistent data 

storage, col. 4, 11. 29-30); 

receive first and second results of processing the first and second data (col. 6, 11. 8-10); 
the first and second data are processed in accordance with first and second 

business objects, respectively, of the plurality of business objects 

forward the first and second results to the first and second computers (col. 6, 11. 8-10, 
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intended to be used with multiple clients Fig. 2) 

maintain a first status of the first client and a second status of a second client (in the form 
of the request) in a first object manager thread and a second object manager thread first object 
manager thread corresponds to a first and second active persistent session (also represented by 
the request, see col. 6, 11. 10-11), (server thread, col. 5, 11. 22-27); 

support an administration framework for monitoring and administration (supports java, 
col. 4, 11. 52-59); 

contains an object manager run-time engine (some section of code) is configured to 
operate on the business objects and the one or more business components (whole document 
operates on servlets). 

Bay eh teaches business objects and business components (servlets, all fit under the broadest 
reasonable interpretation of component and object, and nothing in the specification contradicts 
this) that: 

have logic (processing results , col. 6, 11. 6-8); 

the business objects and the one or more business components comprise one or more 
applets and one or more application objects, which execute on client (web servers return HTML 
pages, see Background Section, these HTML pages contain elements that are rendered [or 
executed] by the browser, and were part of the servlet; these portions of HTML fit under the 
broadest reasonable interpretation of applets and applications objects and nothing in the 
specification contradicts this); 

providing a template for the clients to make a request for a service, providing a template 
for an interface to said server computer, and providing a template for returning a response from 
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said server computer via a web server (the template is the format of an HTTP request and 
response(col. 1, 11. 20-24)); 

represent a service (application processing) request (col. 4, 11. 66-67). 

That the objects are configured to be chosen from horizontal applications, vertical 
applications and internet applications, is at best an intended use of the object. 
Bayeh teaches at least two clients computers (Fig. 2, the below limitations apply to both unless 
otherwise noted): 

comprising a UI (col. 9, 11. 29-31): 

supported by a common framework (HTTP, col. 1, 11. 15-28); 
Having no business logic (a browser has no business logic); 

with what is clearly a standard PC 101/102-key keyboard (see keyboard of Fig. 1, 
magnified in the attached appendix of the Final Rejection of 1/8/2009). Such a keyboard 
inherently includes a tab key button; 

transmit data to server via session based network connections, the session based network 
connections are configured to provide persistent sessions between said first and second client 
computers and said server computer using a plurality of session-based network protocols that 
connect said first and second clients to said object manager Bayeh-914 teaches the connections 
are TCP connections (col. 4, 11.16-17); 

connections are persistent (c65-15). TechNet is cited as evidence that a TCP connection 
is a session-based connection (p. 1, last bullet and "How TCP works", para. 2), 

Bayeh-914 teaches transmission of data to the server through a web client as described 
above, but is silent to the specific key that is pressed, in response to which they are submitted. 
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Cote teaches a web client (web form) that in response to a user hitting the tab key (the onblur 
event handler is fired when focus changes off on the input field; a tab key press changes focus; 
thus the tab key press fires the onblur event) transmits the data request (onblur="submit ( ) "). 
It would have been obvious to one of ordinary skill in the art at the time of the invention to use 
that tab key to transmit the data for both clients, because it was a desired way to submit data ("zY 
will do what you want it to do (automatically submit). ") 

The above combination does not disclose sending in a compressed format. Whalen 
discloses sending information in a compressed format (col. 4, 11. 22-25). It would have been 
obvious to one of ordinary skill in the art at the time of the invention to send the information in a 
compressed format because it would have improved efficiency (col. 1, 11. 45-49). 

The above combination does not disclose how the repository is managed, or role based 
visibility. Salas teaches web server objects (analogous to Bayeh's servlets) that support role- 
based data visibility rules (col. 13 line 61 to col. 14 linel 1). Salas also teaches a server enforcing 
a plurality of repository-defined business processes and rules (col. 3, 11. 1-22). It would have 
been obvious to one of ordinary skill in the art at the time of the invention to add the role-based 
visibility because only a member who has rights will see items they are supposed to (col. 14, 11. 
3-7), and because managing the repository defined rules is desirable because one would 
implicitly not want to violate any rules. 

Regarding dependent claim(s) 22, Bayeh-914 teaches the object manger is multi-threaded, and 
therefore inherently multi-tasking (col. 1, 11. 52-55). Bayeh-914 discloses maintaining the states 
(col. 6, 11. 9-12). 
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Regarding dependent claim(s) 23, 24, Bayeh-914 teaches the clients are at least two different 
types of client technology (col. 4, 11. 6-9). 

11. Claims 28, 31-32 and 34-35 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Bayeh, and further in view of Cote and further in view of Whalen. 
Regarding independent claim(s) 28, Bayeh-914 teaches at least a first and second computer 
systems (Fig. 2, 30a-c), with what is clearly a standard PC 101/102-key keyboard (see keyboard 
of Fig. 1 magnified in the attached appendix). Such a keyboard inherently includes a tab key 
button. Bayeh-914 teaches first and second interfaces (Web Clients, col. 5, 11. 2-6), supported by 
a common framework (HTTP, col. 1, 11. 15-28). Bayeh-914 teaches a server comprising an 
object manager, the web server, comprising business objects that contain business logic, the 
servlets (col. 4, 11. 49- 64). Bayeh-914 teaches the server handles the requests from the clients 
and dispatches them to the servlets or objects (col. 5, 11. 2-15), as well tracks whether they are in- 
use (col. 1, 11. 60-62), and therefore provides common control and monitoring. Bayeh-914 
teaches at least a first and second request (col. 5, 11.2-6), inherently comprising a first and second 
data that define the request, from a first and second client computers (Fig. 2, 30a-c). Bayeh-914 
teaches that each object returns results (col. 6, 11. 5-8). Therefore the requests were processed in 
accordance with the object, and received by the object manager and forwarded to the client. 
Bayeh-914 teaches the connections are TCP connections (col. 4, 11.16-17). TechNet is cited as 
evidence that a TCP connection is a session-based connection (p. 1, last bullet and "How TCP 
works", para. 2). 

Bayeh-914 teaches transmission of data to the server through a web client as described 
above, but is silent to the specific key that is pressed, in response to which they are submitted. 
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Cote teaches a web client (web form) that in response to a user hitting the tab key (the onblur 
event handler is fired when focus changes off on the input field; a tab key press changes focus; 
thus the tab key press fires the onblur event) transmits the data request (onblur="submit ( ) "). 
It would have been obvious to one of ordinary skill in the art at the time of the invention to use 
that tab key to transmit the data for both clients, because it was a desired way to submit data ("zY 
will do what you want it to do (automatically submit). ") 

The above combination does not disclose sending in a compressed format. Whalen 
discloses sending information in a compressed format (col. 4, 11. 22-25). It would have been 
obvious to one of ordinary skill in the art at the time of the invention to send the information in a 
compressed format because it would have improved efficiency (col. 1, 11. 45-49). 
Regarding dependent claim(s) 31 and 32, the above combination does not expressly describe a 
sales business object or customer service business object. The broadest reasonable 
interpretations of these objects are objects that return results pertinent to sales and customer 
service, respectively. Bayeh-914 instead teaches a general object and is silent as to the type of 
data being received. However, these differences are only found in the nonfunctional descriptive 
material and are not functionally involved in the steps recited. All the functions of the apparatus 
would be performed the same way regardless of whether the objects returned sales data, 
customer service data, or any type of data. Thus, this descriptive material will not distinguish the 
claimed invention from the prior art in terms of patentability, see In re Gulack, 703 F.2d 1381, 
1385, 217 USPQ 401,404 (Fed. Cir. 1983); In re Lowry, 32 F.3d 1579, 32 USPQ2d 1031 (Fed. 
Cir. 1994). Therefore, it would have been obvious to a person of ordinary skill in the art at the 
time the invention was made to return results of any category (including sales and customer 
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service), therefore having any category of object (including a sales business Object and a 
customer Service business object) because such data does not functionally relate to the steps in 
the method claimed and because the subjective interpretation of the data does not patentably 
distinguish the claimed invention. 

Regarding dependent claim(s) 34 and 35, Bayeh-914 teaches the clients are at least two 
different types of client technology (col. 4, 11. 6-9). 

12. Claims 29-30 are rejected under 35 U.S.C. 103(a) as being unpatentable over Bayeh- 
914, Cote, Whalen, and as applied to claim 28 above, and further in view of Applicant's 
Admitted Prior Art. 

Regarding dependent claim(s) 29, the above combination does not specifically mention 
encryption, however does operate under the HTTP protocol. Applicant admits (as per MPEP 
2144. 03.C, no traversal of Official Notice of 06/02/2006 is taken as an admission) that HTTPS 
an encrypted version of HTTP was well-known and frequently used in place of HTTP when 
security was necessary at the time of the invention. It would have been obvious to one of 
ordinary skill in the art at the time of the invention to use HTTPS rather the HTTP to prevent 
unauthorized data intrusion, a well-known desirable goal at the time of the invention. 
Regarding dependent claim(s) 30, the above combination does not specifically mention 
authentication, however does operate under the HTTP protocol. Applicant admits (as per MPEP 
2144. 03.C, no traversal of Official Notice of 06/02/2006 is taken as an admission) that HTTP 
requests requiring authentication were well-known and frequently used when security was 
necessary at the time of the invention. It would have been obvious to one of ordinary skill in the 
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art at the time of the invention to use HTTP authentication to prevent unauthorized data 
intrusion, a well-known desirable goal at the time of the invention. 

Response to Arguments 

13. Applicant's arguments with respect to claim 21 have been considered but are moot in 
view of the new ground(s) of rejection. 

14. With respect to claim 28 and its dependents, similar amendments to claim 21were not 
made, and the claims are still rejected as described above. 

Conclusion 

15. The prior art made of record and not relied upon is considered pertinent to applicant's 
disclosure. 

16. Applicant's amendment necessitated the new ground(s) of rejection presented in this 
Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 
Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within TWO 
MONTHS of the mailing date of this final action and the advisory action is not mailed until after 
the end of the THREE-MONTH shortened statutory period, then the shortened statutory period 
will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 
CFR 1 .136(a) will be calculated from the mailing date of the advisory action. In no event, 
however, will the statutory period for reply expire later than SIX MONTHS from the date of this 
final action. 
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17. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to ADAM M. QUELER whose telephone number is (571)272-4140. 
The examiner can normally be reached on Monday-Friday. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Stephen Hong can be reached on (571) 272-4124. The fax phone number for the 
organization where this application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would 
like assistance from a USPTO Customer Service Representative or access to the automated 
information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 

/Adam M Queler/ 
Primary Examiner 
Art Unit 2178 



